

ELECTRONIC CATALOG MAINTENANCE SYSTEM FOR ENABLING 



OUT- OF -STANDARD ELECTRONIC CATALOG CHANGES 



5 BACKGROUND OF THE INVENTION 
FIELD OF THE INVENTION 

The present invention relates to an electronic catalog 
maintenance system for maintaining an electronic catalog 
10 formed according to a prescribed standard such as IS013584. 

DESCRIPTION OF THE BACKGROUND ART 

IS013584 (Parts Library) is the conventionally known 
international standard for implementing the electronic 

15 catalog system for electronically providing product 
information on the Internet. In this IS013584, the 
electronic catalog is formed by dictionary data and 
contents (catalog data) , which are given in a unified data 
structure in order to realize sharing and reuse of the 

20 product information. 

In the dictionary data defined by IS013584, the 
product classification is expressed hierarchically as in an 
example shown in Fig. 27, by relating "product classes" AO, 
BO, Bl and C0-C3 by a single tree structure. Each of the 

25 "product classes" AO. BO, Bl , C0-C3 has "attribute items" 
V0-V6, and the "attribute items" of one "product class" 
(such as VO and VI belonging to BO, for example) are 
inherited to the lower "product classes" (CO and CI). 



30 "BSU (Basic Semantic Unit) code" is to be assigned to each 
one of the "product classes" and the "attribute items" in 
order to identify it uniquely. Note that the "attribute 



only be referred and "Applicable" type attribute items for 
35 which actual values can be entered. The "Applicable" type 



Also, in IS013584, a unique ID (identifier) called 



item 



s" includes "Visible" type attribute items which can 
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attribute items are to be selected from "Visible" type 
attribute items that can be referred (VO of C2 , for 
example ) . 

While IS013584 provides a framework for the electronic 
5 catalog, the international standardization of actual 
dictionary data is also in progress, and IEC61360 is 
currently striving for the standardization of the upper 
hierarchy part of the dictionary data in the field of 
electric and electronic products, that is, the general part 

10 regarding the "product classes" and the "attribute items". 
As a result, a product catalog producer of each company can 
creates that company's own contents by determining the 
original detailed "product classes" and "attribute items" 
as a lower level development from IEC61360. 

15 A user of the electronic catalog can retrieve a 

desired product from the contents created in this way by 
tracing the classification hierarchy of the "product 
classes" and narrowing down products that can meet his/her 
needs by referring to attribute values. In recent years. 

20 several systems in compliance with 1S013584 have been 
developed in this trend. 

In IS013584 described above, a basic idea of the 
maintenance regarding a dictionary system formed according 
to the definition is described, and in particular, a 

25 mechanism based on Version/Revision updates is described 
for management of the dictionary. 

Figs. 28A and 28B summarize that basic idea. In Fig. 
28A, a way of handling each type is described for addition, 
change, and deletion of associated information of the 

30 attribute item (property ). Also , in Fig. 28B, a way of 

handling each type is described for addition, change, and 
deletion of associated information of the product class 
(which will be referred to hereafter as "class"). 

However, according to the agreement shown in Figs. 28A 

35 and 28B , changes of the dictionary are very limited, and in 
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particular, changes required in the following cases cannot 
be handled. 

Case 1) Deletion of Visible/Applicable Property 
Case 2) Change of Visible/Applicable Property 



inherited, among changes of Super Class 

Case 4) Change of Name scope of Visible Property 
Note however that, in Case 2). the "Version UP of 
Property" event is excluded, and addition of 

10 Visible/Applicable Property can be handled by Version up. 

Note also that, in Case 3). the "Version UP of Super 
Class" event is excluded, and change which does not delete 
a Property to be inherited such as insertion of an 
intermediate class can be handled by Version up, while 

15 change of Preferred Name can be handled by Revision up. 

Now, it is expected that these Case 1) to Case 4) will 
occur frequently in practice as in the case of changing the 
class hierarchy structure. For example, they are expected 
to occur in the case of newly creating a class (FFF) at an 

20 end (FEE) of the tree structure as shown in Fig. 29, the 
case of deleting an end class (HHH) as shown in Fig. 30, 
the case of merging a plurality of product classes (FEE and 
HHH) to one product class (KKK) as shown in Fig. 31, the 
case of moving the product class (HHH or DDD) as shown in 

25 Figs. 32. 33, 34 and 35. and the case of creating or 

deleting an Intermediate class (HHH) as shown in Figs. 36 
and 37. 

Consequently, it is practically very important to 
enable handling of such cases as Case 1) to Case 4) by 
30 going beyond the framework of IS013584. However, the 
following problems are encountered in realizing this. 

First, the BSU code that is once issued and disclosed 
cannot be deleted and must be permanently managed even when 
it becomes unused as it is taken out from the dictionary 
35 system, because there is a possibility of referencing from 
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Case 3) Change which deletes a Property to be 
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the legacy system, so that there is a need to be compatible 
with the legacy system. 

Second, one class or attribute can be regarded as a 
number of different classes or attributes when the 
5 hierarchy structure is changed, even if the definition and 
the content of that class or attribute as a single entity 
remain unchanged. This will cause a large number of the new 
issuance of the BSU code and the releasing of the BSU code 
so that the management of codes becomes very difficult. For 
10 this reason, there is a need to provide a function for 
comprehending the new issuance of the BSU code. 

Q SUMMARY OF THE INVENTION 

It is therefore an object of the present invention to 

''3 provide an electronic catalog maintenance system capable of 

^1 improving usefulness and generality of the electronic 

Si catalog by ensuring the freedom of changes of the 

20 electronic catalog, while making the changed electronic 

rlj catalog data utilizable even in the conventional systems. 
SJf' According to one aspect of the present invention there 

•i: t3 

Q is provided an electronic catalog maintenance system, 

comprising: a dictionary database configured to store 

25 dictionary data of an electronic catalog, the dictionary 
data being given in a form of a tree structure formed by 
identifiers for uniquely identifying classes classifying 
products and attributes of the products; an editing unit 
configured to edit the dictionary data stored by the 

30 dictionary database by making changes including standard 
changes defined by a prescribed standard and out-of- 
standard changes not defined by the prescribed standard; a 
change status detection unit configured to detect a status 
of each change made by the editing unit, and to generate an 

35 identifier change data indicating the status of each change 
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made by the editing unit and updates of identifiers to be 
made in the distrionary data; an identifier update unit 
configured to issue a new identifier of each class or 
attribute created by an out-of -standard change made by the 
5 editing unit, and to retire an old identifier of each class 
or attribute deleted by an out-of -standard change made by 
the editing unit, according to the identifier change data 
generated by the change status detection unit; and an 
identifier change database configured to store the 

10 identifier change data generated by the change status 
detection unit. 

According to another aspect of the present invention 
there is provided an electronic catalog maintenance method, 
comprising the steps of: (a) storing dictionary data of an 

15 electronic catalog in a dictionary database, the dictionary 
data being given in a form of a tree structure formed by 
identifiers for uniquely identifying classes classifying 
products and attributes of the products; (b) editing the 
dictionary data stored by the dictionary database by making 

20 changes including standard changes defined by a prescribed 
standard and out-of -standard changes not defined by the 
prescribed standard; (c) detecting a status of each change 
made by the step (b) , and generating an identifier change 
data indicating the status of each change made by the step 

25 (b) and updates of identifiers to be made in the dictionary 
data; (d) issuing a new identifier of each class or 
attribute created by an out-of -standard change made by the 
step (b). and releasing an old identifier of each class or 
attribute deleted by an out-of -standard change made by the 

30 step (b), according to the identifier change data generated 
at the step (c); and (e) storing the identifier change data 
generated by the step (c) in an identifier change database. 

According to another aspect of the present invention 
there is provided a computer usable medium having computer 

35 readable program codes embodied therein for causing a 
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computer to function as an electronic catalog maintenance 
system, the computer readable program codes include: a 
first computer readable program code for causing said 
computer to store dictionary data of an electronic catalog 
5 in a dictionary database, the dictionary data being given 
in a form of a tree structure formed by identifiers for 
uniquely identifying classes classifying products and 
attributes of the products; a second computer readable 
program code for causing said computer to edit the 

10 dictionary data stored by the dictionary database by making 
changes including standard changes defined by a prescribed 
standard and out-of -standard changes not defined by the 
prescribed standard; a third computer readable program code 
for causing said computer to detect a status of each change 

15 made by the editing unit, and to generate an identifier 
change data indicating the status of each change made by 
the editing unit and updates of identifiers to be made in 
the dictionary data; a fourth computer readable program 
code for causing said computer to issue a new identifier of 

20 each class or attribute created by an out-of -standard 
change made by the editing unit, and to retire an old 
identifier of each class or attribute deleted by an out-of- 
standard change made by the editing unit, according to the 
identifier change data generated by the third computer 

25 readable program code; and a fifth computer readable 
program code for causing said computer to store the 
identifier change data generated by the third computer 
readable program code in an identifier change database. 

Other features and advantages of the present invention 

30 will become apparent from the following description taken 
in conjunction with the accompanying drawings, 

BRIEF DESCRIPTION OF THE DRAWINGS 

35 
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Fig. 1 is a block diagram showing an overall 
configuration of an electronic catalog maintenance system 
according to one embodiment of the present invention. 

Fig. 2 is a diagram showing an example of class data 
5 in electronic catalog dictionary data used by the 
electronic catalog maintenance system of Fig. 1. 

Fig. 3 is a diagram showing an example of attribute 
data in electronic catalog dictionary data used by the 
electronic catalog maintenance system of Fig. 1. 
10 Fig. 4 is a diagram showing an example of class- 

attribute relationship data in electronic catalog 
dictionary data used by the electronic catalog maintenance 
system of Fig. 1. 

Fig. 5 is a diagram showing an example of class BSU 
15 code change data in BSU code change data used by the 
electronic catalog maintenance system of Fig. 1. 

Fig, 6 is a diagram showing an example of attribute 
BSU code change data in BSU code change data used by the 
electronic catalog maintenance system of Fig. 1. 
20 Fig. 7 is a diagram showing an exemplary model for 

expressing version tree data and revision tree data used by 
the electronic catalog maintenance system of Fig. 1. 

Fig. 8 is a diagram showing an exemplary data 
description of version tree data and revision tree data 
25 used by the electronic catalog maintenance system of Fig. 
1. 

Fig. 9 is a diagram showing an example of dictionary 
system quality data used by the electronic catalog 
maintenance system of Fig. 1. 
30 Fig. 10 is a flow chart for an overall processing of 

the electronic catalog maintenance system of Fig. 1. 

Fig. 11 is a flow chart for a processing by a master 
database management unit at the step S3 of Fig. 10. 

Fig. 12 is a flow chart for a processing by an editing 
35 database management unit at the step S4 of Fig. 10. 
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Fig. 13 is a flow chart for a processing by a 
dictionary change status detection function at the step S13 
of Fig. 10. 

Fig. 14 is a diagram showing an example of change type 
5 discrimination rules used by the electronic catalog 
maintenance system of Fig. 1. 

Fig. 15 is a flow chart for a processing by a summary 
generation function with respect to class data at the step 
S16 of Fig. 10. 

10 Fig. 16 is a flow chart for a processing by a summary 

generation function with respect to attribute data at the 
step S16 of Fig. 10. 

Fiff. 17 is a diagram showing an exemplary manner of 
Q changing BSU codes due to dictionary data editing at the 

]f 15 step S12 of Fig. 10. 

Sji Fig. 18 is a diagram showing class BSU code change 

•''3 data and its summary generated as a result of changes shown 

in Fig. 17. 

Si Fig. 19 is a diagram showing attribute BSU code change 

i2 20 data and its suBamary generated as a result of changes shown 

in Fig. 17. 

Fig. 20 is a flow chart for a processing by a 
dictionary system quality check function at the step S17 of 
Fig. 10. 

25 Fig. 21A is a diagram showing an example of quality 

check rules used by the electronic catalog maintenance 
system of Fig. 1 . 

Fig. 21B is a diagram showing an example of BSU code 
issuance rules used by the electronic catalog maintenance 
30 system of Fig. 1. 

Fig. 22 is a flow chart for a processing by an editing 
database management unit at the step S18 of Fig. 10. 

Fig. 23 is a flow chart for a processing by a BSU code 
update function with respect to class data at the step S22 
35 of Fig. 10. 
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Fig. 24 is a flow chart for a processing by a BSU code 
update function with respect to attribute data at the step 
S22 of Fig. 10. 

Fig. 25 is a flow chart for a processing by a master 
5 database management unit at the step S23 of Fig. 10. 

Fig. 26 is a diagram showing computer readable 
recording media for recording an electronic catalog 
maintenance program according to the present invention. 

Fig, 27 is a diagram showing an exemplary electronic 
10 catalog data structure according to 1S013584. 

Fig. 28A is a diagram showing Version/Revision update 
rules for property (attribute) as defined by IS013584. 

Fig. 28B is a diagram showing Version/Revision update 
rules for class (attribute) as defined by 1S013584. 
15 Fig. 29 is a diagram showing an exemplary BSU code 

change due to an electronic catalog change for creation of 
end class. 

Fig. 30 is a diagram showing an exemplary BSU code 
change due to an electronic catalog change for deletion of 
20 end class. 

Fig. 31 is a diagram showing an exemplary BSU code 
change due to an electronic catalog change for merging of 
classes . 

Fig. 32 is a diagram showing an exemplary BSU code 
25 change due to an electronic catalog change for moving of a 
class. 

Fig, 33 is a diagram showing an exemplary BSU code 
change due to an electronic catalog change for moving of a 
class. 

30 Fig. 34 is a diagram showing an exemplary BSU code 

change due to an electronic catalog change for moving of a 
class . 

Fig. 35 is a diagram showing an exemplary BSU code 
change due to an electronic catalog change for moving of a 
35 class. 
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Fig. 36 is a diagram showing an exemplary BSU code 
change due to an electronic catalog change for creation of 
an intermediate class. 

Fig. 37 is a diagram showing an exemplary BSU code 
5 change due to an electronic catalog change for deletion of 
an intermediate class, 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

10 

Referring now to''Fig. 1 to Fig. 26, one embodiment of 
the electronic catalog maintenance system according to the 
present invention will be described in detail. 

(Overall configuration of the electronic catalog 
15 maintenance system) 

Fig. 1 shows a schematic configuration of the 
electronic catalog maintenance system according to this 
embodiment . 

As shown in Fig. 1, the electronic catalog maintenance 

20 system of this embodiment comprises a dictionary editor 1, 
a BSU code change management function 2, a dictionary 
change status detection function 5, a dictionary system 
quality check function 6, an editing database management 
unit 7, a master database management unit 8, an electronic 

25 catalog dictionary editing database 14, a BSU code change 
management editing database 16, an electronic catalog 
dictionary master database 20, and a BSU code change 
management master database 22. 

The dictionary editor 1 newly creates or edits the 

30 electronic catalog dictionary data 10. In this embodiment, 
this dictionary editor 1 can store the newly created or 
edited electronic catalog dictionary data 10 into the 
electronic catalog dictionary editing database 14 or the 
electronic catalog dictionary master database 20, and read 

35 out the electronic catalog dictionary data 10 from the 
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electronic catalog dictionary editing database 14 or the 
electronic catalog dictionary master database 20 and edit 
them. 

The BSU code change management function 2 has a 
5 suimnary generation function 3 and a BSU code update 

function 4, The summary generation function 3 generates a 
summary of changes by deleting redundant portion from the 
BSU code change data 9 at a time of storing the electronic 
catalog dictionary data 10. The BSU code update function 4 

10 updates the BSU codes in the electronic cataqlog dictionary 
data 10 according to the generated summary and BSU code 
issuance rules 11. 

The dictionary change status detection function 5 
detects how BSU codes will be affected by the editing of 

15 the electronic catalog dictionary data 10 made by the 

dictionary editor 1 according to change type discrimination 
rules 12. and generates the BSU code change data 9. 

The dictionary system quality check function 6 checks 
a quality of the updated electronic catalog dictionary data 

20 10 according to quality check rules 13, and generates 
dictionary system quality data 26. 

The editing database management unit 7 manages data 
input/output with respect to the electronic catalog 
dictionary editing database 14 and the BSU code change 

25 management editing database 16. 

The master database management unit 8 manages data 
input/output with respect to the electronic catalog 
dictionary master database 20 and the BSU code change 
management master database 22. 

30 The electronic catalog dictionary data 10 updated as a 

result of the editing or the like will be stored into the 
electronic catalog dictionary editing database 14 by the 
editing database management unit 7, as editing electronic 
catalog dictionary data 15. Also, the BSU code change data 

35 9 that became the summary and the dictionary system quality 
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data 26 are stored into the BSU code change management 
editing database 16 by the editing database management unit 
7 similarly, as editing BSU code change data 17 and editing 
dictionary system quality data 19 respectively. At a time 

5 of storing these data, the editing database management unit 
7 generates and manages Revision Tree data 18 describing 
relationships among these data in order to carry out the 
revision management of the dictionary. 

Among the electronic catalog dictionary data 15 stored 

10 in the electronic catalog dictionary editing database 14, 
data to be used as a disclosure version which have a high 
level of completeness will be sent to the master database 
management unit 8, and managed in the electronic catalog 
dictionary master database 20 as master electronic catalog 

15 dictionary data 21. At the same time, the corresponding 
editing BSU code change data 17 and the corresponding 
editing dictionary system quality data 19 will be also 
stored in the BSU code change management master database 22 
as master BSU code change data 23 and master dictionary 

20 system quality data 25 respectively. At a time of storing 
these data, the master database management unit 8 generates 
and manages Version Tree data 24 describing relationships 
among these data In order to carry out the version 
management of the dictionary. 

25 (Configuration of the electronic catalog dictionary 

data) 

Next, the contents of the electronic catalog 
dictionary data 10 or 15 to be stored in the electronic 
catalog dictionary editing database 14 and edited by the 
30 dictionary editor 1 will be described. Fig. 2 to Fig. 4 
show exemplary configurations of the electronic catalog 
dictionary data 10 or 15. 

Fig. 2 shows an example of class data in the 
electronic catalog dictionary data 10 or 15, where one line 
indicates information of one class. In this information, a 
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"CID" which is an ID for identifying the class internally, 
a "BSU" which describes a BSU code of the class, and a 
"parent class CID" which describes a CID of a class that is 
a parent on the hierarchy structure of classes will be 
automatically assigned by the dictionary editor 1 and the 
BSU code change management function 2 in this embodiment. 
Note that the electronic catalog dictionary data 10 or 15 
in this embodiment contain associated information of the 
class as specified by IS013584 including a "Preferred Name" 
which indicates a name of the class, and this will be 
entered by a user. Also, a value of a "data quality level- 
in this electronic catalog dictionary data 10 or 15 will be 
written by the dictionary system quality check function 6. 
Fig. 3 shows an example of attribute data in the 
15 electronic catalog dictionary data 10 or 15. where one line 
indicates information of one attribute. In this 
information, a "PID" which is an ID for identifying the 
attribute internally and a "BSU" which describes a BSU code 
of the attribute will be automatically assigned by the 
20 dictionary editor 1 and the BSU code change management 
function 2 in this embodiment. There is also associated 
information of the attribute as specified by 1S013584 
including a "Preferred Name" which indicates a name of the 
attribute, and this will be entered by a user. Also, a 
25 value of the data quality level will be written by the 
dictionary system quality check function 6. 

Fig. 4 shows an example of class-attribute 
relationship data in the electronic catalog dictionary data 
10 or 15, where one line indicates information of one 
30 class-attribute relationship. In this information, a 

"CID_scope" describes a class for which this attribute is 
defined, a "Visible" describes a list of classes that can 
be referred by this attribute, and "Applicable" describes a 
list of classes to which this attribute can be applied. 
35 (Configuration of the BSU code change data) 
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Next, the contents of the BSU code change data 9 or 17 
to be generated by the editing of the electronic catalog 
dictionary data 10 or 15 by the dictionary editor 1 and 
stored in the BSU code change management editing database 
5 16 will be described. Fig. 5 and Fig. 6 show exemplary 
configurations of the BSU code change data 9 or 17. 

Fig. 5 shows an example of BSU code change data for 
classes in the BSU code change data 9 or 17 where one line 
indicates information of one BSU code change event. In this 
10 information, a "Status" indicates an event type which can 
take four values (VUP. RUP , NEW. GOD). Here, "VUP" and 
"RUP" indicate change events in accordance with the 
Version/Revision management specification of IS013584 as 
shown in Figs. 28A and 28B. Also, "NEW" indicates one for 
15 which there is a need to newly issue a BSU code as a result 
of a change event. Also. "OOD" indicates one for which 
there is a need to retire a BSU code as it is excluded 
from the dictionary system. 

For each "Status", "CID" of the class with respect to 
20 which the change is made, "BSU", and "Refer_to" and 
"Same_as" which indicate relationships of generation 
changes among classes are given. Using these two 
relationships, it is possible to access the registered 
class through the generation change, even in the case of 
25 making access to the dictionary by using a retired BSU code 
which is already excluded from the dictionary system. 

Fig. 6 shows an example of BSU code change data for 
attributes in the BSU code change data 9 or 17, where one 
line indicates information of one BSU code change event. In 
30 this information, a "Status" indicates an event type which 
can take four values (VUP, RUP, NEW, OOD). Here, "VUP" and 
"RUP" indicate change events in accordance with the 
Version/Revision management specification of IS013584 as 
shown in Figs. 28A and 28B . Also, "NEW" indicates one for 
35 which there is a need to newly issue a BSU code as a result 
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of a change event. Also, "OOD" Indicates one for which 
there is a need to retire a BSU code as it is excluded 
from the dictionary system. 

For each "Status". "PID" of the attribute with respect 
to which the change is made. "BSU". and "Refer_to" and 
"Same_as" which indicate relationships of generation 
changes among attributes are given. Using these two 
relationships, it is possible to access the registered 
attribute through the generation change, even in the case 
of making access to the dictionary by using a retired BSU 
code which is already excluded from the dictionary system. 
(Configuration of Version Tree data) 

Next, the Version Tree data to be stored in the BSU 
code change management editing database 16 or the BSU code 
change management . master database 22 will be described. 

Fig. 7 shows a model for expressing the Version Tree 
data 24 and the Revision Tree data 18 used in Fig. 1 in 
terms of EXPRESS-G, which is an ER model in which a 
rectangle represents an entity and a line represents a 
relation . 

In Fig. 7. a "DB_Version" entity represents the master 
electronic catalog dictionary data 21. a "Version_History" 
entity represents the master BSU code change data 23, a 
"DB_Revision" entity represents the editing electronic 
catalog dictionary data 10, a "Revision_History" entity 
represents the editing BSU code change data 17, and a 
"DB_quality" entity represents the editing dictionary 
system quality data 19 and the master dictionary system 
quality data 25. 

Fig. 8 shows an exemplary data description of the 
Version Tree data 24 and the Revision Tree data 18. which 
is described according to a model shown in Fig. 7, and 
which will be used as information for the version 
management of each data. In Fig. 8, a portion enclosed by 
an enclosure 30 represents the Version Tree data 24, and a 
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portion enclosed by an enclosure 31 represents the Revision 
Tree data 18. 

(Configuration of the dictionary system quality data) 
Next, the contents of the dictionary system quality 
data 26 to be generated by the dictionary system quality 
check function 6 will be described. 

Fig. 9 shows an example of the dictionary system 
quality data 26, where quality evaluation values are 
described from viewpoints of classes, attributes, and the 
entire dictionary itself. These values are calculated by 
the dictionary system quality check function 6 by 
evaluating the electronic catalog dictionary data 10 and 
the BSU code change data 9 according to the quality check 
rules 13. 

(Processing by the electronic catalog maintenance 
system) 

The electronic catalog maintenance system of this 
embodiment in the above described configuration carries out 
the electronic catalog maintenance operation as follows. 
Fig. 10 shows a flow chart for an overall processing to be 
carried out by the electronic catalog maintenance system of 
this embodiment. 

As shown in Fig. 10, when the dictionary editor 1 is 
activated (step SI), whether the electronic catalog 
dictionary data to be edited is a new one or an existing 
one is judged (entered) (step S2) . Then, in the case of 
newly creating an electronic catalog dictionary, the 
processing for generating a new dictionary is carried out 
at the steps S3 and S4, whereas in the case of reading 
existing data, whether that data is stored in the 
electronic catalog dictionary editing database 14 or the 
electronic catalog dictionary master database 20 is judged 
(step 85). In the case of reading from the electronic 
catalog dictionary editing database 14, the processing of 
the step Sll is carried out, whereas in the case of reading 
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from the electronic catalog dictionary master database 20. 
the processing of the steps S6 to SIO is carried out. 

Next, the electronic catalog dictionary data 10 so 
created or read will be changed by the editing processing 
of the step S12. Then, the content of that change is 
checked by the processing of the step S13. Namely, the 
dictionary change status detection function 5 compares the 
editing content, made by the dictionary editor 1 with the 
change type discrimination rules 12 to determine the 
editing content as one of a Revision UP change, a Version 
UP change and a New BSU change, and generates the check 
result as the BSU code change data 9. 

When it is desired to store the edited electronic 
catalog dictionary data 10 (step S14 YES and step S15 YES). 
15 it is stored into the electronic catalog dictionary editing 
database 14 (step S18) after the summary generation 
processing of the step S16 and the quality check processing 
of the step S17. On the other hand, when it is desired to 
store the electronic catalog dictionary data 10 with a high 
20 level of completeness as the master data (step S19 YES), it 
is stored into the electronic catalog dictionary master 
database 20 (step S23) after the quality of the dictionary 
is confirmed at the steps S20 and S21 . and the BSU code is 
issued and the Version/Revision update is carried out at 

25 the step S22. 

In the following, each processing will be described in 
further detail. Fig. 11 shows a flow chart for a processing 
to be carried out by the master database management unit 8 
in the processing of the step S3 of Fig. 10. that is the 
processing for newly creating the electronic catalog 
dictionary data 10. 

AS shown in Fig. 11. in the processing of the step S3 
described above, when the master database (name) is entered 
at the step S30 . the Version Tree data 24 based on a model 
shown in Fig. 7 is created and stored by the steps S31 to 
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S34, and the necessary information is transmitted to the 
editing database management unit 7 by the step S35 . Then, 
an empty electronic catalog dictionary data 21 is created 
and stored by the step S36 and an empty BSU code change 
5 data 23 is created and stored by the step S37. 

Fig. 12 shows a flow chart for the processing of the 
step S4 in Fig. 10, that is a processing to be carried out 
by the editing database management unit 7 in the processing 
for newly creating the electronic catalog dictionary data 
10 10. 

As shown in Fig. 12, the necessary information is 
received from the master database management unit 8 at the 
step S40. and the Revision Tree data 18 is created and 
stored by the steps S41 to S45 . Then, an empty electronic 
15 catalog dictionary data 15 is created and stored by the 
step S46 and an empty BSU code change data 17 is created 
and stored by the step S47. At the same time, an empty 
electronic catalog dictionary data 10 is created and stored 
by the step S48 and an empty BSU code change data 9 is 
20 created and stored by the step S49 . 

Fig. 13 shows a flow chart for the processing of the 
step S13 in Fig. 10, that is a processing to be carried out 
by the dictionary change status detection function 5 in the 
processing for checking the change content of the edited 
25 electronic catalog dictionary data 10. 

As shown in Fig. 13. the dictionary change event is 
detected at the step SlOO and discriminated according to 
the change type discrimination rules 12 shown in Fig. 14 at 
the step SlOl. Then, depending on whether the event type is 
30 that related to the class or that related to the attribute 
(step S102). the subsequent steps S103 to SllO are carried 
out when the event type is that related to the class, 
whereas the subsequent steps Sill to S118 are carried out 
when the event type is that related to the attribute, so as 
35 to generate the BSU code change data 9. 
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Fig. 14 shows an example of the change type 
discrimination rules 12 describing the rules to be used in 
the processing of Fig. 13. 

As shown in Fig. 14, the change type discrimination 
rules 12 are largely divided into rules for the product 
class change and the rules for the attribute change, and 
each rule describes a condition for judging whether each 
change is Revision UP, Version UP or New BSU. and a 
processing method suitable for each type. Note that these 
judgement condition and processing method are described in 
the IF-THEN format in this embodiment, but they may be 
described in any other format. 

Then, as a result of the judgement according to the 
change type discrimination rules 12, if the change of the 
BSU code change data 9 is related to the class, whether 
that change is Revision UP. Version UP, or New BSU is 
checked, whether there is a class to be retired or not is 
checked, and the BSU code change data 9 is changed 
according to the rule to be applied. If the change of the 
BSU code change data 9 is related to the attribute, the 
rule to be applied is checked similarly. 

Fig. 15 shows a flow chart for a processing to be 
carried out by the summary generation function 3 with 
respect to the class data in the processing of the step S16 
of Fig. 10. Here, the processing is branched according to 
"Status" of each event described in the BSU code change 
data 9 and the status of BSU code issuance. By this 
processing, the redundant operation can be removed from the 
editing operation, and only significant changes including 
the BSU code change can be extracted. 

Among symbols used in Fig. 15, "Status" indicates the 
"Status" attribute of the class BSU code change data, "BSU" 
indicates the "BSU" attribute of the class BSU code change 
data, "CID" indicates the "CID" attribute of the class BSU 
code change data, "Same_as" indicates "Same_as" attribute 
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of the class BSU code change data, "Refer_to" indicates the 
"Refer_to" attribute of the class BSU code change data, and 
"A. Status" indicates the "Status" attribute value of the 
class BSU code change data A. 

5 Also, among alphabets attached to these symbols, "R" 

indicates the tail end data of the class BSU code change 
data, "X" indicates the class BSU code change data whose 
CID value is equal to "R.Refer_to" value, "S" indicates the 
class BSU code change data whose CID value is that of the 
10 parent (upper level) class of "R.CID" value and whose 

"Status" value is "NEW", "Y" indicates the class BSU code 
change data whose "Status" value is "NEW" and whose CID 
value is equal to "R.CID" value, "Z" indicates the class 
BSU code change data whose "Status" value is "OOD" and 

15 whose "Refer_to" value is equal to "Y.CID" value, "T" 

indicates the class BSU code change data whose "Status" 
value is "VUP" or "RUP" and whose CID value is equal to 
"R.CID" value, and "K" indicates the class BSU code change 
data whose "Status" value is equal to "R. Status" value and 

20 whose CID value is equal to "R.CID" value. 

First, the BSU code change data related to the class 
is read (step S201) , the tail end data R is detected (step 
S202) , and the processing is terminated when the data R 
does not exist (step S203 NO), or otherwise the processing 

25 from the step S204 on is carried out. 

In the processing from the step S204 on, whether 
"R. Status" value is "OOD" or not is judged (step S204) , and 
if "R. Status" is "OOD", whether "R.BSU" value is "NULL" or 
not is judged (step S205). 

30 When it is judged that "R.BSU" value is "NULL" at the 

step S205, Y for which "Y. Status" value is "NEW" and 
"Y.CID" value is equal to "R.CID" value is obtained. Z for 
which "Z. Status" value is "OOD" and "Z.Refer_to" value is 
equal to "Y.CID" value is obtained, and X for which 

35 "X. Status" value is "NEW" and "X.CID" value is equal to 
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"R.Refer_to" value is obtained (steps S209. S210, S211). 
Then, whether such X and Z exist or not is judged (steps 
S212, S213, S215) . Then, depending on a combination of the 
existing X and Z, "NULL" is substituted into "Z.Refer_to" 
5 (step S214), "R.CID" is replaced by "Z.CID" and "X.CID" is 
substituted into "X.Refer_to" (steps S216, S217) , "R.CID" 
is deleted (step S218), every T for which "T. Status" is 
"VUP" or "RUP" and "T.CID" value is equal to "R.CID" value 
is obtained (step S219), and R, Y and T are deleted (step 
10 S220). 

When it is judged that "R.BSU" value is not "NULL" at 
the step S205, X for which "X.CID" value is equal to 
"R.Refer_to" value is obtained (step S206). and if such X 
does not exist (step S207 NO), the parent class S of 

15 "R.CID" is obtained and "S.CID" is set to "R.Refer_to" 
(step S208) . 

On the other hand, when it is judged that the 
"R. Status" value is not "OOD" at the step S204, whether 
"R. Status" value is "NEW" or not is Judged (step S221). and 

20 if it is "NEW", every K for which "K. Status" value is equal 
to "R. Status" value and "K.CID" value is equal to "R.CID" 
value is obtained (step S222) and K is deleted (step S223) . 
Then, whether "R.BSU" is "NULL" or not is judged (step 
S224) , and if so R is deleted (step S225). 

25 After R is obtained in this way, the data immediately 

before R is substituted into this obtained data R (step 
S226), and the next processing is started by the loop 
processing. 

Fig. 16 shows a flow chart for a processing to be 
30 carried out by the summary generation function 3 with 

respect to the attribute in the processing of the step S16 
of Fig. 10. Here, the processing is branched according to 
"Status" of each event described in the BSU code change 
data 9 and the status of BSU code issuance, similarly as 
35 Fig. 15. By this processing, the redundant operation such 
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as a change related to the class that was once newly 
created but then deleted on the second thought, for 
example, can be removed from the editing operation, and 
only significant changes including the BSU code change can 
5 be extracted. 

Among symbols used in Fig. 16. "PID" indicates the 
"PID" attribute of the fittribute BSU code change data, and 
"A.PID" indicates the "FID" attribute value of the class 
BSU code change data A. Also, among alphabets attached to 
10 these symbols, "R" indicates the tail end data of the 

attribute BSU code change data. "X" indicates the attribute 
BSU code change data whose "Status" value is "NEW" and 
whose FID value is equal to "R.Refer_to" value. "Y" 
'3 indicates the attribute BSU code change data whose "Status" 

1 15 value is "NEW" and whose FID value is equal to "R.PID" 

value, "Z" indicates the attribute BSU code change data 
whose "Status" value is "OOD" and whose "Refer_to" value is 
=J equal to "Y.PID" value, "T" indicates the attribute BSU 

\ code change data whose "Status" value is "VUF" or "RUF" and 

20 whose FID value is equal to "R.PID" value, and "K" 

indicates the attribute BSU code change data whose "Status" 
value is equal to "R. Status" value and whose FID value is 
equal to "R.PID" value. 

First, the BSU code change data related to the 
25 attribute is read (step S301) , the tail end data R is 

detected (step S302) , and the processing is terminated when 
the data R does not exist (step S303 NO), or otherwise the 
processing from the step S304 on is carried out. 

In the processing from the step S304 on, whether 
30 "R. Status" value is "OOD" or not is judged (step S304) , and 
if "R. Status" is "OOD". whether "R.BSU" value is "NULL" or 
not is judged (step S305). 

When it is judged that "R.BSU" value is "NULL" at the 
step S305, Y for which "Y. Status" value is "NEW" and 
35 "Y.PID" value is equal to "R.PID" value is obtained. Z for 
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which "Z. Status" value Is "OOD" and "Z,Refer_to" value is 
equal to "Y.PID" value Is obtained, and X for which 
"X. Status" value is "NEW" and "X.PID" value is equal to 
"R.Refer_to" value is obtained (steps S306, S307, S308). 
5 Then, whether such X and Z exist or not is judged (steps 
S309, S310. S312). Then, depending on a combination of the 
existing X and Z, "NULL" is substituted into "Z.Refer_to" 
(step S311). "R.PID" is replaced by "Z.PID" and "X.PID" is 
substituted into "X.Refer_to" (steps S313, S314), "R.PID" 
10 is deleted (step S315), every T for which "T. Status" is 

"VUP" or "RUP" and "T.PID" value is equal to "R.PID" value 
is obtained (step S316), and R, Y and T are deleted (step 
S317), 

Q On the other hand, when it is Judged that the 

15 "R. Status" value is not "OOD" at the step S304, whether 

"R. Status" value is "NEW" or not is Judged (step S318) , and 
if it is "NEW", every K for which "K. Status" value is equal 
to "R. Status" value and "K.PID" value is equal to "R.PID" 
value is obtained (step S319) and K is deleted (step S320). 
20 Then, whether "R.BSU" is "NULL" or not is Judged (step 
S321) , and if so R is deleted (step S322). 

After R is obtained in this way. the data immediately 
before R is substituted into this obtained data R (step 
S323) , and the next processing is started by the loop 
25 processing. When it is Judged that "R.BSU" value is not 
"NULL" at the step S305, and when it is Judged that 
"R. Status" value is "NEW" at the step S318. this step S323 
is carried out immediately. 

(Change of the BSU code) 
30 In the following, the concrete examples of the 

electronic catalog maintenance by the electronic catalog 
maintenance system described above will be described. Fig. 
17 shows an exemplary BSU code change by the dictionary 
data editing processing of the step S12 of Fig. 109. 
35 First, as shown in a part (a) of Fig. 17, suppose that 
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Bl is deleted and the note of CO is changed. As a result, 
as shown in a part (b) of Fi&. 17. C2 and C3 located below 
the deleted Bl are directly connected below AO as C4 and 
C5, and Revision UP of CO for which the note is changed is 
5 carried out. At this point, C2 and C3 located below the 
deleted Bl are set in retired states, and V4. V5 and V6 
that are belonging only to Bl, C2 and C3 are also set in 
retired states. 

Next, when C4 and C5 are merged, as shown in a part 

10 (c) of Fig. 17. a new C6 is created instead of the merged 
C4 and C5 . and C4 and C5 are set in retired states. At this 
point, V7, V8, V9 and VIO that are belonging only to the 
merged C4 and C5 are also set in retired states, and Vll, 
V12, Via and V14 are newly added instead of them. 

15 (Summary generation) 

In the case of making such a change in the electronic 
catalog dictionary data, the BSU code change data for the 
class and the attribute created by the change and their 
summary will be generated as follows. 

20 A part (a) of Fig. 18 shows the class BSU code change 

data created by the dictionary change status detection 
function 5 when the operations of Fig. 17 are carried out. 
Then, by carrying out the processing of Fig. 15 described 
above with respect to these data, these data are updated as 

25 shown in parts (b) to (e) of Fig. 18. In this way, it can 
be seen that only the significant change operations for the 
class are extracted. 

Fig. 19 shows the attribute BSU code change data 
created by the change of Fig. 17 and a manner of generating 

30 their summary. 

A part (a) of Fig. 19 shows the attribute BSU code 
change data created by the dictionary change status 
detection function 5 when the operations of Fig. 17 are 
carried out. Then, by carrying out the processing of Fig. 

35 16 described above with respect to these data, these data 
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are updated as shown in parts (b) to (1) of Fig. 19. In 
this way, it can be seen that only the significant change 
operations for the attribute are extracted. 
(Quality check of the dictionary) 
5 Next, the operation of the dictionary quality check 

function, which is one of the functions of the electronic 
catalog maintenance system of this embodiment, will be 
described. Fig. 20 shows a flow chart for a processing of 
the dictionary system quality check function 6 to generate 
10 the dictionary system quality data 26 in the processing of 
the step SIT of Fig. 10. 

First, by the steps S401 to S407 of Fig. 20, the class 
BSU code change data that became the summary are read, a 
O top data R is obtained, the quality of individual class is 

■J :.i 

15 evaluated according to the quality check rules 13, and its 

Cil value is written into the "data quality level" field of the 

Z class data, 

sua 

Here, as the quality check rules 13, tables formed by 
: the evaluation conditions and the evaluation functions as 

20 shown in Fig. 21A can be used, for example. As shown in 
il-f Fig. 21A, the quality check rules 13 can be formed from the 

Q evaluation of individual class, the evaluation of 

individual attribute, the evaluation regarding the class 
hierarchy structure, the evaluation regarding the attribute 
25 overlaps, and the evaluation regarding the entire 

dictionary, for example. Note that the quality evaluation 
is made by calculating the quality level by using such 
quality check rules 13 in this embodiment, but it is also 
possible to account for the Importance of associated items, 
30 and it is also possible to set evaluation functions based 
on different evaluation axes. 

Then, at the steps S408 and S409, the overall quality 
of the class data such as the consistency of the hierarchy 
structure for example is evaluated according to the quality 
35 check rules 13, and added to the dictionary system quality 
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data 26. In addition, at the steps S410 to S416. the 
quality of individual attribute is evaluated according to 
the quality check rules 13 and its value is written into 
the "data quality level" field of the attribute data. 
5 Next, at the steps S417 and S418, the overall quality 

of the attribute data such as the overlapping existence of 
identical definitions for example is evaluated according to 
the quality check rules 13, and added to the dictionary 
system quality data 26. Then, at the step S419, the 
10 dictionary system quality data 26 are evaluated according 
to the quality check rules 13, and the quality level of the 
entire electronic catalog dictionary is calculated and 
added to the dictionary system quality data 26. 



=^3 (Processing by the editing database management unit 7) 

5 2 15 The data produced by each processing described above 

Cn are stored by the editing database management unit 7. Fig. 

''i 22 shows a flow chart for a processing of the editing 

•a database management unit 7 to store data in the processing 

r of the step S18 of Fig. 10. 

U 20 As shown in Fig. 22, at the steps S501 to S509. the 



DB_Revision entity and the Revision_History entity for 
describing relationships between the BSU code change data 9 
and the electronic catalog dictionary data 10 that are 
desired to be stored in order to carry out the revision 

25 management of the dictionary are generated, and stored into 
the Revision Tree data 18. 

Next, at the step S510 to S513, the quality 
information of the dictionary is obtained from the 
dictionary system quality data 26, and the DB_quality 

30 entity is generated and stored in the Revision Tree data 18 
similarly. Then, at the step S514, the BSU code change data 
9 created by the summary generation function 3 are stored 
into the BSU code change management editing database 16 as 
the editing BSU code change data 17. Finally, at the step 

35 S515, the electronic catalog dictionary data 10 is stored 
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into the electronic catalog dictionary editing database 14 
as the editing electronic catalog dictionary data 15. 
(Processing of BSU codes) 

Next, the BSU code change management processing by the 
5 BSU code update function 4 will be described. Fig. 23 shows 
a flow chart for a processing by the BSU code update 
function 4 to update the class data in the processing of 
the step S22 of Fig. 10. and Fig. 24 shows a flow chart for 
a processing by the BSU code update function 4 to update 
10 the attribute data in the processing of the step S22 of 
Fig. 10. 

In the case of the processing for updating the class 
data, as shown in Fig. 23, the processing is carried out 
according to the "Status" value of the BSU code change data 

15 9 read by the step S601. 

Namely, when it is judged that "Status" is "VUP" at 
the step S603. the Version UP is carried out at the steps 
S604 to S608. On the other hand, when it is judged that 
"Status" is not "VUP" at the step S603 and it is Judged 

20 that "Status" is "RUP" at the step S609, the Revision UP is 
carried out at the steps S610 to S614. Else, when it is 
judged that "Status" is not "VUP" at the step S603 and it 
is judged that "Status" is not "RUP" at the step S609, 
whether "Status" is "NEW" or not is judged (step S615), and 

25 if "Status" is "NEW", the steps S616 to S618 are carried 

out according to the BSU code issuance rules 11 as shown in 
Fig. 21B. such that the new BSU code is issued and written 
into the BSU field of the class data. 

Also, in the case of the processing for updating the 

30 attribute data, as shown in Fig. 24, the processing is 

carried out according to the "Status" value of the BSU code 
change data 9 read by the step S701 . 

Namely, when it is judged that "Status" is "VUP" at 
the step S703, the Version UP is carried out at the steps 

35 S704 and S705. On the other hand, when it is judged that 
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"Status" is not "VUP" at the step S703 and it is judged 
that "Status" is "RUP" at the step S706 , the Revision UP is 
carried out at the steps S707 and S708. Else, when it is 
judg-ed that "Status" is not "VUP" at the step S703 and it 
5 is judged that "Status" is not "RUP" at the step S706, 

whether "Status" is "NEW" or not is Judged (step S709). and 
if "Status" is "NEW", the steps S710 to S712 are carried 
out according to the BSU code issuance rules 11 as shown in 
Fig, 21B, such that the new BSU code is issued and written 
10 into the BSU field of the attribute data. 

(Processing by the master database management unit 8) 
The electronic catalog dictionary data with a high 
j.". level of completeness are stored into the electronic 

O catalog dictionary master database 20 as the master 

.'I 15 electronic catalog dictionary data 21. Fig. 25 shows a flow 

tn chart for a processing of the master database management 

unit 8 to store data in the processing of the step S23 of 
'•J Fig. 10. 

: As shown in Fig. 25, at the steps S801 to S806 , the 

Is. 20 DB_Version entity and the Version_History entity for 

describing relationships between the BSU code change data 9 
and the electronic catalog dictionary data 10 that are 
desired to be stored in order to carry out the version 
management of the dictionary are generated, and stored into 
25 the Version Tree data 24. 

Next, at the step S807 to S810 , the quality 
information of the dictionary is obtained from the 
dictionary system quality data 26, and the DB_quality 
entity is generated and stored in the Version Tree data 24 
30 similarly. Then, at the step S811 , the BSU code change data 
9 created by the summary generation function 3 are stored 
into the BSU code change management master database 22 as 
the master BSU code change data 23. Finally, at the step 
S812, the electronic catalog dictionary data 10 is stored 
35 into the electronic catalog dictionary master database 20 
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as the master electronic catalog dictionary data 21. 
(Electronic catalog maintenance program) 
Note that the electronic catalog maintenance system 
described above can be realized by producing an electronic 
5 catalog maintenance program described in a prescribed 
programming language and installing this maintenance 
program into a general purpose computer such as PC, for 
example . 

Namely, an electronic catalog maintenance software can 

10 be formed by a program for detecting the change status of 
the electronic catalog dictionary data 10 due to the 
editing by the dictionary editor 1 or the like and 
generating the BSU code change data 9 when the change that 
is out of the standard such as 1 SOI 3584 is made , and a 

15 program for recording the changed electronic catalog 
dictionary data 10 and the BSU code change data 9. 

Note that in this electronic catalog maintenance 
software, it is preferable to include a program for 
generating the summary by simplifying the BSU code change 

20 data 9 by deleting the redundant portion from the change 
history of the BSU code change data 9 as described above . 

This electronic catalog maintenance software may also 
include a program for setting the BSU codes used before the 
change in retired states when the change status is out of 

25 the standard such as IS 01 3584 and newly issuing 

corresponding codes to the catalog data or the dictionary 
data relevant to the out -of- standard change , and a program 
for generating and storing the BSU code change data 9 that 
records the correspondence between the retired BSU codes 

30 and the newly issued BSU codes . 

This electronic catalog maintenance software may also 
include a program for evaluating the quality of the 
electronic catalog dictionary system and each element 
constituting the changed electronic catalog dictionary data 

35 10 according to the quality check rules 13. generating the 
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dictionary system quality data 26, and storing the 
dictionary system quality data 26 into the BSU code change 
management editing database 16. 

The electronic catalog maintenance software so 
produced can be recorded on recording media 116-119 that 
are readable by a general purpose computer 115 as shown in 
Fig. 26. More specifically, as shown in Fig. 26, this 
electronic catalog maintenance software can be recorded on 
computer readable recording media such as a magnetic 
recording medium like a floppy disk 116 or a cassette tape 
119. an optical disk like a CD-ROM 117, and a RAM card 118. 

Then, by using such computer readable recording media 
that record this electronic catalog maintenance software, 
it is possible to easily realize storing, carrying, and 
installing of a useful program that has an effect of 
enabling the efficient electronic catalog change management 
and ensuring generality of the electronic catalog by 
carrying out the comprehensive version management for the 
electronic catalog dictionary data relevant to the change 
operation , 

As described, according to the electronic catalog 
maintenance system of the present invention, it becomes 
possible to enable the efficient electronic catalog change 
management and ensure generality of the electronic catalog 
by carrying out the comprehensive version management for 
the electronic catalog dictionary data relevant to the 
change operation such that the electronic catalog can be 
utilized without requiring a major modification to the 
existing systems. 

Here, the prescribed electronic catalog standard can 
be any international standard such as IS013584 (Parts 
Library) and IEC61360 , for example. Also, the product 
classification information can be given by "product class 
(class)" or "attribute item (property)", for example. Also, 
the identifier can be given by BSU code, for example. 
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Also, the out-of -standard changes Include addition or 
deletion of an Intermediate hierarchy, issuance of new 
identifier, and a change of the tree structure that causes 
an occurrence of an identifier in a retired state. This 
5 change status can be detected according to Version/Revision 
updates, presence or absence of a new identifier (ID), and 
presence or absence of an identifier (ID) in a retired 
state, for example. 

Thus, according to the present invention, it is 
10 possible to make the electronic catalog change management 
easier by comparing the electronic catalog before and after 
the change by utilizing the history information, and it is 
possible to improve degrees of freedom in the electronic 
catalog change operations by enabling the out-of -standard 
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Also, according to the present Invention, it is 
possible to make the change processing management easier by 
deleting unnecessary change processing (of the case where 
there is no change eventually or the case where there is 

20 only a minor change) such as those occurring in the case of 
the editing in which the changes are made repeatedly by 
trial and error, for example, from the history information. 

Also, according to the present invention, it is 
possible to make access to the contents relevant to the 

25 out-of -standard change from a newly issued identifier, so 

that this system can be used in the legacy system and it is 
possible to ensure usefulness and generality of the 
electronic catalog . 

Also, according to the present invention, it is 

30 possible to realize the change status management in 

accordance with the international standard such as IS013584 
(Parts Library) and IEC61360, for example, so that it is 
possible to improve generality of the electronic catalog. 
Also, according to the present invention, it is 

35 possible to distinguish a minor change at a time of the 
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change operation and a formal change at a time of 
disclosure as a formal version up by selecting the storage 
unit according to the level of completeness of the 
electronic catalog, so that it is possible to provide the 
5 high quality dictionary. 

Also according to the present invention, it is 
possible to improve the quality of the electronic catalog 
by evaluating the quality of the electronic catalog 
dictionary system and each element constituting the changed 
10 electronic catalog by using the dictionary system quality 
check function. 

It is also to be noted that, besides those already 
mentioned above, many modifications and variations of the 



Q above embodiments may be made without departing from the 

1^ 15 novel and advantageous features of the present invention, 

ill Accordingly, all such modifications and variations are 

intended to be included within the scope of the appended 
'=:J claims . 
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